-
Notifications
You must be signed in to change notification settings - Fork 383
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support ya sub
subcommand for the Ya CLI
#1004
Conversation
630d772
to
29da37a
Compare
29da37a
to
bd9ee17
Compare
Ideally, I don't want to add new Can you describe the issues you encountered when reading the output of |
The error I get is the following:
I realize it's not much to work with. Here's a code snippet that causes that error for me: local events_job = vim.system({ 'yazi', "--remote-events='hover'" }, {
text = true,
stderr = function(_, data)
vim.notify('stderr: ' .. vim.inspect(data))
end,
stdout = function(_, data)
vim.notify('stdout: ' .. vim.inspect(data))
end,
}) The error does not occur if I start |
d89997b
to
fabd343
Compare
Just rebased to |
The suggestions have now all been addressed. However, some odd issues now remain that I would like to see fixed:
|
Yeah this is the expected behavior.
Try
When |
Thanks for the instructions! I was able to implement reconnecting, and it's much better now. However, there is some odd behaviour when starting up: about 2000 empty messages are received. As a proof of concept, I added a hacky counter to display the number of the current message. Here's a very short demo: yazi-messages.movI'm not sure what this might mean. Could you try this out and see if you get the same behaviour? |
Why is this PR closed? |
There are two reasons:
I could maybe see such an integration layer being implemented in lua, perhaps
As you explained in |
c46b247
to
c19fc51
Compare
The motivations for this change are: - easy debugging of DDS messages for yazi and plugin developers - allow external applications to monitor yazi events. In neovim specifically, there is a limitation that the stdout and stderr streams cannot be monitored when displaying an embedded terminal application. A second yazi instance could theoretically be started, but the ui does currently not work when there is no screen to draw on.
- don't start a new server. Instead, crash if the server is not running. - remove support for listening for a specific peer. The protocol doesn't support it and it cannot be made to work. - if the existing yazi closes, this cannot be detected, and the connection is never reestablished. Maybe this can be made to work in a future commit.
If the connection cannot be made when starting, the client will fail and not reconnect. However, if the connection is lost after the client has started, it will forever attempt to reconnect with a 1s delay. Also clean up the implementation by removing previous mistakes
3e9a0d9
to
2d3cd4d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me now, thanks for contributing this feature!
ya sub
subcommand for the Ya CLI
The motivations for this change are:
ya-sub-static-demo.mov
In neovim specifically, there is a limitation that the stdout and stderr streams cannot be monitored when displaying an embedded terminal application. A second yazi instance could theoretically be started, but the ui does currently not work when there is no screen to draw on.